系統重構應該使用甚麼開發技術？

前面已經確認全面重構的範圍、既有系統行為、保留資料及遷移方式。接下來要為目標系統選擇程式語言、框架（Framework）、資料保存方式、測試工具與建置工具，讓後續實作有一致基礎。

適合的技術取決於目標系統需要解決的問題。流行度、開發人員的個人偏好或單一效能數字，都不足以支持長期使用的決定。選擇過程需要先排除不符合限制的候選項目，再比較維護成本與風險，最後用實際結果處理仍無法確定的問題。

先把需求轉成技術選擇條件

功能需求（Functional Requirements）說明目標系統要完成哪些工作，非功能需求（Non-functional Requirements）則說明這些工作需要達到的品質。兩者都要轉成能檢查的技術條件，否則「效能良好」、「容易維護」或「安全」仍然無法用來比較候選技術。

可以先從下列內容建立選擇條件：

• 將必要功能對程式語言、框架、資料處理及輸入輸出能力的需求記錄成明確條件。
• 將回應時間、處理量、可用性、安全性、可擴充性及恢復時間等品質要求改寫成可測量的驗收條件。
• 確認目標作業系統、執行環境、可用執行資源及部署限制，排除無法在目標條件下穩定運作的選項。
• 確認目標系統需要讀寫的資料格式、互動方式與相依項目，以及它們實際支援的版本與連線方式。
• 確認資料遷移、並行驗證、正式切換及必要復原程序會對技術組合增加哪些要求。
• 記錄開發、測試、除錯、升級與維護工作可投入的人力及時間。

每個條件還要標示它的用途：

這項分類可以避免將偏好誤寫成必要條件，也能防止真正的限制被評分總數掩蓋。例如，目標執行環境無法支援某個語言執行環境的版本時，該選項就不應該因為開發工具方便而保留。

評估完整的技術組合

程式語言、框架、資料保存方式與開發工具會互相影響。只挑選其中一項，無法確認整套開發與執行流程是否成立。比較候選方案時，需要把會一起使用的項目組成一個方案，再檢查各項目之間的版本相容性與責任邊界。

程式語言與相關執行環境

程式語言要能表達目標系統的功能，也要有適合的編譯、測試、除錯及分析工具。候選版本需要受到維護，並且能在目標環境執行。現有開發與維護人員的經驗可以降低初期風險，但仍要確認這些經驗是否涵蓋目前版本、測試方法及目標系統需要的功能。

如果候選語言需要新增一套執行環境，還要評估版本管理、更新方式、建置時間、啟動時間與執行資源。選用熟悉的語言也不代表風險必然較低。如果既有經驗只適用於停止維護的版本，升級與重新學習仍然需要列入成本。

框架

框架可以提供固定的程式結構、生命週期及常用功能，但也會限制升級路徑與部分設計方式。評估時需要確認它是否支援目標功能、測試方式及執行環境，並且檢查核心功能是否依賴少數停止維護的擴充項目。

框架功能較多不等於更適合。目標系統只需要少數功能時，額外抽象層次可能增加除錯與升級成本。需求複雜且多項功能需要一致處理時，成熟的框架則可能減少重複實作。判斷重點是實際會使用哪些能力，以及這些能力是否能被測試和維護。

資料保存方式

如果目標系統需要保存狀態，就要根據資料關係、查詢方式、一致性、交易範圍、資料量、保存期限及遷移條件選擇資料保存方式。既有系統使用某種資料庫，只能作為相容性條件，不能直接決定沿用相同產品。更換資料保存技術也需要由目標需求支持。

候選方案必須能表達已確認的資料規則，並且支援資料遷移與結果驗證。需要和既有資料來源並行一段時間時，還要確認驅動程式、字元編碼、資料型別及識別方式是否相容。資料模型、遷移程序與正式切換的詳細設計，仍以已確認的資料處理需求為準。

測試與建置工具

測試工具需要支援目標系統預定採用的測試層次，並且能自動執行、清楚回報失敗原因。建置工具則要能從已保存的原始碼與設定產生可重複驗證的成果。兩者都要確認版本相容性、執行方式及維護狀態，不能等到功能實作完成後才補上。

程式語言、框架與工具鏈也要使用彼此相容的版本。候選方案如果只能依靠大量未記錄的人工步驟才能建置或測試，就會增加環境差異與維護風險。環境固定與套件版本管理的實作方式會在後續章節繼續說明，本章只確認所選技術具備建立這些流程的能力。

確認長期維護條件

目標系統在正式切換後仍需要修正、更新與擴充。技術選擇因此要涵蓋預計使用期間，不能只比較第一次完成開發所需的時間。

每項候選技術至少要確認下列內容：

• 查明正式版本的支援期限、安全性更新方式，以及重大問題由誰處理。
• 檢查版本升級是否有清楚文件、相容性說明、棄用通知及可演練的轉換方式。
• 確認必要函式庫、驅動程式與開發工具是否持續維護，並且具有可接受的授權條件。
• 使用官方文件完成代表性工作，確認關鍵流程不必依賴零散或過時的說明。
• 評估問題發生時能否從文件、原始碼、維護者或可取得的專業人力找到處理方式。
• 記錄安裝、建置、測試、部署、監控及升級需要維護的項目數量，避免只比較撰寫功能的速度。

採用新的技術可能改善型別檢查、測試或開發工具，也會增加學習與初期除錯時間。沿用熟悉技術可以降低轉換成本，但前提是版本仍受支援，並且能滿足目標需求。兩種方向都要使用相同條件比較，不能先決定結論再補理由。

檢查遷移與並行期間的相容性

全面重構需要在完成驗收前保留既有系統，因此技術組合還要支援分析、遷移、比對與正式切換。這些工作未必由目標系統本身執行，但相關工具必須能交換可驗證的資料。

可以按照實際情況確認下列問題：

• 目標技術能否正確處理既有資料的字元編碼、日期、數值精度、空值與識別內容？
• 如果系統保留既有資料來源，候選驅動程式是否支援其實際產品與版本？
• 如果需要和其他系統互動，候選方案能否產生並解析既有資料格式，並且保留錯誤與逾時資訊？
• 資料遷移工具、比對程式與目標系統能否使用一致的規則解讀資料？
• 並行驗證期間，兩套系統的輸出能否使用穩定方式比較，而不需要每次人工轉換？
• 正式切換或切換回既有系統時，候選方案是否會增加無法在可用時間內完成的轉換工作？

相容性不能只看產品支援清單。清單通常無法回答特定版本、資料型別、錯誤處理或實際處理量是否符合需求。影響切換的項目需要使用代表性資料及目標環境驗證。

用概念驗證處理高風險問題

概念驗證用來回答技術選擇中的特定未知事項。它不需要完成正式功能，但必須重現足以影響決策的條件。只做出可以操作的展示畫面，無法驗證大量資料處理、外部整合、部署或錯誤復原等風險。

執行概念驗證時，可以採用下列步驟：

1. 將待確認事項改寫成能通過或失敗的問題，例如「能否在指定時間內處理代表性資料量」。
2. 選擇一條具代表性的完整功能路徑，涵蓋必要輸入、系統規則、資料處理與輸出。
3. 固定候選技術版本、目標環境、輸入資料、操作步驟與測量方式，讓不同方案可以比較。
4. 除了正常流程，也測試無效輸入、相依項目失敗、重新執行與資源不足等已識別風險。
5. 記錄建置、測試、除錯、更新與部署過程，確認維護工作是否存在無法接受的限制。
6. 按照預先設定的通過條件判斷結果，不因已投入時間而降低標準。

概念驗證產生的程式可以捨棄。需要保留的是測試條件、使用版本、執行結果、失敗原因與決策影響。如果驗證環境或輸入資料和目標條件差異太大，結果就只能用來說明該次實驗，不能直接推論正式環境也會相同。

使用評估表比較候選方案

通過必要條件的方案可以使用評估表比較。權重應該反映已確認需求，分數則要附上文件、測試結果或概念驗證紀錄。沒有資料支持的分數要標示為待確認，不能用印象填入。

分數可以協助整理差異，不能取代必要條件或風險判斷。兩個方案總分接近時，可以比較最高風險項目、驗證結果可信度與失敗後的替換成本，不需要為了產生唯一答案而調整分數。

用架構決策紀錄保存決策與限制

選定技術後，需要使用架構決策紀錄（Architecture Decision Record, ADR）保存當時的問題、選項與理由。ADR 保存當時的判斷脈絡，讓後續維護人員知道這項決定依據哪些條件，以及何時需要重新評估。

一份技術選擇 ADR 可以包含：

1. 背景：記錄要解決的問題、適用範圍與重要限制。
2. 決策：寫明採用的技術、版本範圍及它在目標系統中的責任。
3. 候選方案：列出實際比較過的選項，不加入未評估的名稱充數。
4. 判斷依據：連結需求、評估表、概念驗證及相容性測試結果。
5. 影響：記錄採用後獲得的能力、需要承擔的成本與已知限制。
6. 重新評估條件：列出支援終止、需求改變、重大弱點或驗證結果失效等觸發條件。

ADR 要和目標系統原始碼及相關文件一起管理。候選技術版本、需求或驗證結果改變時，應該新增後續決策紀錄並保留原本脈絡，不要只修改結論而刪除原因。

何時可以完成技術選擇？

技術選擇完成時，應該得到一套能共同運作的技術組合，以及足以支持後續設計與實作的決策紀錄。至少要確認下列結果：

• 所有候選方案都已通過必要條件，或已記錄排除原因。
• 高風險的效能、資料、整合、部署與版本相容性問題已完成概念驗證。
• 程式語言、相關執行環境、框架、資料保存方式及工具版本彼此相容。
• 開發與維護人員能完成建置、測試、除錯、更新及必要的問題處理。
• 技術組合能支援資料遷移、並行驗證、正式切換與後續維護。
• 評估表與 ADR 已記錄採用理由、已知限制及重新評估條件。

如果關鍵結果仍是「理論上支援」或「之後再確認」，技術選擇就還沒有完成。先縮小未知範圍並取得可重現的結果，可以避免後續功能已大量實作後才發現基礎技術不符合限制。

重點整理

• 開發技術要從功能需求、非功能需求、目標環境、相依項目及切換限制推導，並區分必要條件、比較條件與待確認事項。
• 程式語言、相關執行環境、框架、資料保存方式、測試工具與建置工具需要組成完整方案，再檢查版本相容性及責任邊界。
• 技術評估要同時考量支援週期、升級方式、文件、必要相依項目、開發能力及長期維護成本。
• 資料遷移、並行驗證與正式切換需要使用實際版本、代表性資料及目標環境確認相容性。
• 概念驗證要回答明確的高風險問題，並保存測試條件、執行結果、失敗原因與決策影響。
• 評估表可以比較通過必要條件的候選方案，ADR 則保存採用理由、已知限制與重新評估條件。